Automated routing based on content metadata

ABSTRACT

Methods, computer readable media, and devices for automated routing based on content metadata are provided. One method may include receiving a user request for content with metadata from a client by a content distribution network (CDN), parsing the user request for content to generate an evaluation of the metadata, determining a routing decision representing a selection of one of a plurality of origin services for the user request for content based on the evaluation of the metadata, transmitting the user request for content to the selected one of the plurality of origin services based on the routing decision, receiving a response to the user request for content from the selected one of the plurality of origin services, and sending the response to the client.

TECHNICAL FIELD

Embodiments disclosed herein relate to techniques and systems for makingrouting decisions based on metadata associated with an applicationprogramming interface (API).

BACKGROUND

Content Delivery Networks (CDNs) typically use geo-proximate domain nameservices (DNS) to route user requests from the users' browsers anddevices through the internet to the geographically closest CDN edgenodes to themselves. The edge nodes typically perform services such asterminating secure socket layer (SSL) requests, maintaining caching forsome content, and providing some levels of protection for the originserver such as protection against denial-of-service (DOS) attacks, webapplication firewall (WAF) protections, and the like. Edge nodestypically maintain longer-lived connections back to the origin serverand proxy requests to that server for the real content serving. Theremay be different CDN configurations for each origin server, configuredvia DNS. That is, for each origin server, the users may use differentDNS entries.

BRIEF DESCRIPTION OF THE DRAWINGS

The accompanying drawings, which are included to provide a furtherunderstanding of the disclosed subject matter, are incorporated in andconstitute a part of this specification. The drawings also illustrateimplementations of the disclosed subject matter and together with thedetailed description explain the principles of implementations of thedisclosed subject matter. No attempt is made to show structural detailsin more detail than can be necessary for a fundamental understanding ofthe disclosed subject matter and various ways in which it can bepracticed.

FIG. 1 is a block diagram illustrating a conventional contentdistribution network (CDN) system according to some exampleimplementations.

FIG. 2 is a block diagram illustrating a CDN system for routing based oncontent metadata according to some example implementations.

FIG. 3 is a flow diagram illustrating a method for automated routingbased on content metadata according to some example implementations.

FIG. 4A is a block diagram illustrating an electronic device accordingto some example implementations.

FIG. 4B is a block diagram of a deployment environment according to someexample implementations.

DETAILED DESCRIPTION

Various aspects or features of this disclosure are described withreference to the drawings, wherein like reference numerals are used torefer to like elements throughout. In this specification, numerousdetails are set forth in order to provide a thorough understanding ofthis disclosure. It should be understood, however, that certain aspectsof disclosure can be practiced without these specific details, or withother methods, components, materials, or the like. In other instances,well-known structures and devices are shown in block diagram form tofacilitate describing the subject disclosure.

FIG. 1 shows an example of a conventional content distribution network(CDN) configuration. In this example, users in each geographic region(US users 102, EU users 104, and APAC users 106) access the originserver(s) 130 through the internet 110 via one or more edge nodes (USedge node 122, EU edge node 124, and APAC edge node 126) available to,and configured to serve, their geographic region. For example, US edgenode 122 is available to and configured to server US users 102.Similarly, EU edge node 124 is available to and configured to serve EUusers 104 while APAC edge node 126 is available to and configured toserve APAC users 106. However, such conventional CDN configuration maynot take into account various criteria, such as an intended destination,performance, latency, or the like.

In embodiments of the present disclosure, the CDN edge devices may beused to provide a component of an application programming interface(API) middleware system. Embodiments disclosed herein may provide APIcaching, routing, and service protection components.

To do so, edge workers may be created that are able to examine metadata,such as instance elements of the uniform resource identifier (URI) path,headers, and/or configuration associated with a user request for contentwill be delivered via a CDN. In some cases, dynamic elements such aslatency may be taken into consideration in order to abstract away thebackend systems and perform dynamic routing decisions.

Using such a technique, the same domain name service (DNS) and same edgeworkers may be used to route to different origin services. For example,based on the URI path elements of a user request that indicate the typeof service associated with the request, the request may be automaticallyrouted to the appropriate origin service. Other aspects such as theidentity of the tenant wishing to be reached, the latency incommunicating to a given service instance, or other metadata may be usedto select an appropriate routing.

Once the API requests arrive at a given service, the service may applyother API policies at that level. Embodiments consistent with thisapproach provide alternative means to perform distributed trafficrouting for APIs and thereby avoid funneling all traffic through singlepoints of failure that must be maintained, operated, and scaled.Instead, small function-as-a-service style workers are leveraged at theedge nodes to absorb this scale.

The approach disclosed herein also may allow for web-based services toexpose a single endpoint that provides the API surface, so that endusers only see one DNS point that can route request to different tenantsstored in different technical stacks.

For example, the edge workers may route and expose different functionsdepending on whether a user request represents a business-to-business(B2B) or business-to-customer (B2C) login. The end users and end userdevices need not access separate sites or services with different URIsdepending upon which type of service is needed; rather, the dynamic edgerouting process automatically identifies each request as B2B or B2C androutes it to the appropriate origin service, as shown in FIG. 2.

As a specific example, an athletic shoe manufacturer may provide aconfiguration site that allows users or retailers to customize a shoefor end-user or retailer purchase. The same configuration tool may beprovided both on the end-user facing site (B2C) of the manufacturer, aswell as a retailer-facing (B2B) using only a single embeddable componentwith a single API. The user request may be routed appropriately based onmetadata in the request.

As another example, a cart/checkout system on an e-commerce site may usedifferent backend origin services than a product display on the samesite. It may be desirable to mask the DNS source and technology stackfor one or both services. In embodiments disclosed herein, the originservices are effectively hidden behind the end point edge workers andthe DNS source at the origin server(s) are not exposed to the end users.

Implementations of the disclosed subject matter provide methods,computer readable media, and devices for automated routing based oncontent metadata. In various implementations, a method may includereceiving, by a content distribution network (CDN), a user request forcontent including metadata from a client, parsing the user request forcontent to generate an evaluation of the metadata, determining a routingdecision representing a selection of one of a plurality of originservices for the user request for content based on the evaluation of themetadata, transmitting the user request for content to the selected oneof the plurality of origin services based on the routing decision,receiving a response to the user request for content from the selectedone of the plurality of origin services, and sending, by the CDN, theresponse to the client.

In some implementations, the user request for content may be anapplication programming interface (API) call.

In some implementations, the metadata may include one or more elementsselected from the group consisting of: a uniform resource identifier(URI) path; a header; a configuration; an identification; a latency; andinformation associated with a source of the user request for content.

In various implementations, the method may further include caching theresponse prior to sending the response to the client.

In various implementations, the method may further include receiving asecond user request for content including second metadata from theclient, parsing the second user request for content to generate a secondevaluation of the second metadata, determining a second routing decisionfor the second user request for content representing a selection of adifferent one of the plurality of origin services based on the secondevaluation of the second metadata, transmitting the second user requestfor content to the selected different one of the plurality of originservices based on the second routing decision, receiving a secondresponse to the second user request for content from the selecteddifferent one of the plurality of origin services, and sending thesecond response to the client.

In various implementations, the method may further include receiving asecond user request for content including second metadata from a secondclient, parsing the second user request for content to generate a secondevaluation of the second metadata, determining a second routing decisionfor the second user request for content representing a selection of adifferent one of the plurality of origin services based on the secondevaluation of the second metadata, transmitting the second user requestfor content to the selected different one of the plurality of originservices based on the second routing decision, receiving a secondresponse to the second user request for content from the selecteddifferent one of the plurality of origin services, and sending thesecond response to the client.

FIG. 2 shows an example of a system for performing CDN routing based onrequest metadata as disclosed herein. As with a conventional CDN system,users in different regions (US users 202, EU users 204, and APAC users206 in this example) may send requests for various sites or servicesthrough the internet 110 to an intended origin site. Each request may beprocessed by an edge worker, such as US edge worker 222, EU edge worker224, and APAC edge worker 226, that examines metadata in the requestitself, such as a requested URI, requestor information such as logincredentials, originating site, or the like, and other metadataassociated with the request such as the latency, identification of anassociated tenant, or the like. Some metadata may be included in therequest or may be otherwise determined depending on the specificimplementation. For example, individual requests may include a tenantidentifier, or the appropriate tenant may be identified using othertechniques.

Based upon this metadata, the receiving edge worker may route therequest to an appropriate backend service, such as service A US1 cell232, service A US2 cell 234, service A EU1 cell 236, service B EU1 cell238, service C APAC1 cell 240, or the like. Several examples areprovided, but it will be understood that, more generally, any requestfrom an end user may be routed to any appropriate backend service orserver using the same techniques. Some requests may be sent to differentproviders of the same service, such as where requests handled by US edgeworker 222 may be routed to service A US1 cell 232 or service A US2 cell234, servers, data centers, or the like depending upon a tenant IDassociated with the request. As a specific example, “Service A” may be acustomer relationship management application that is used by multipletenants of a multi-tenant system. Based upon the tenant ID, the requestmay be routed to the appropriate provider. The tenant ID may be includedin the request or may be identified by other means, such as a source IPaddress, source organization, login credentials of the requesting user,or the like.

As another example, the request may be routed by the URI path includedin the request. In this example, two requests from the EU region may berouted to different services (service A EU1 cell 236 and service B EU1cell 238) based on the URI path in the request.

In still another example, the request may be routed based on latency,such as latency between an edge work and the origin services. In thisexample, two requests from the APAC region may be routed to differentservices (service B EU1 cell 238 and service C APAC1 cell 240) based onlatency between APAC edge worker 226 and the two services.

In various implementations, each edge worker may reference a set ofrules as part of making a routing decision. For example, US edge worker222 may reference rules 212, EU edge worker 224 may reference rules 214,and APAC edge worker 226 may reference rules 216. As such, an edgeworker may base a routing decision on metadata contained in or otherwiseassociated with a user request as well as rules available to the edgeworker.

FIG. 3 illustrates a method 300 for automated routing based on contentmetadata, as disclosed herein. In various implementations, the steps ofmethod 300 may be performed by a server, such as electronic device 400of FIG. 4A or system 440 of FIG. 4B, and/or by software executing on aserver or distributed computing platform. Although the steps of method300 are presented in a particular order, this is only for simplicity.

In step 302, a user request for content may be received. For example, anedge worker of a CDN may receive a user request from a client. Invarious implementations, the user request for content may includemetadata, such as a URI path, a header, a configuration, anidentification, a latency, information associated with a source of theuser request for content, or the like. Such metadata may be included aspart of the user request and/or otherwise associated with the userrequest (e.g., an edge worker may determine a latency between the edgeworker and one or more origin services to which the request may berouted). In some implementations, the user request for content may be anAPI call.

In step 304, the user request for content may be parsed to generate anevaluation of the metadata. For example, an edge worker may parse themetadata to identify one or more criteria on which to base a routingdecision.

In step 306, a routing decision for the user request for content may bedetermined. For example, an edge worker may select one of a plurality oforigin services to which the user request will be routed. In variousimplementations, such routing decision determination may be based on theevaluation of metadata generated in step 304. In some implementations,an edge worker may reference one or more sets of rules as part of therouting decision determination. For example, such rules may define a setof criteria on which an edge worker may base a selection of one of aplurality of origin services. In one example, one such rule may indicatethat a primary origin services is to be utilized if latency is below acertain threshold and a secondary origin services is to be utilized iflatency is above the threshold.

In step 308, the user request for content may be transmitted to aselected origin service based on the determined routing decision. Instep 310, a response from the selected origin service may be received.

In optional step 312, the received response may be cached. For example,the edge worker may cache the response in storage accessible by the edgeworker. Such caching may be based, for example, on the rules used tomake a routing decision and/or on a configuration of the CDN.

In step 314, the received response may be transmitted to the client. Forexample, the edge worker may transmit the response to the client fromwhich the user request was received.

As can be seen, automated routing based on content metadata, asdescribed herein, may improve the performance of existing computingsystems by enabling better utilization of available resources, such asorigin services. In addition, improved protection of critical resourcesmay be achieved by hiding a resource's true identity with a commonidentity associated with a CDN.

One or more parts of the above implementations may include software.Software is a general term whose meaning can range from part of the codeand/or metadata of a single computer program to the entirety of multipleprograms. A computer program (also referred to as a program) comprisescode and optionally data. Code (sometimes referred to as computerprogram code or program code) comprises software instructions (alsoreferred to as instructions). Instructions may be executed by hardwareto perform operations. Executing software includes executing code, whichincludes executing instructions. The execution of a program to perform atask involves executing some or all of the instructions in that program.

An electronic device (also referred to as a device, computing device,computer, etc.) includes hardware and software. For example, anelectronic device may include a set of one or more processors coupled toone or more machine-readable storage media (e.g., non-volatile memorysuch as magnetic disks, optical disks, read only memory (ROM), Flashmemory, phase change memory, solid state drives (SSDs)) to store codeand optionally data. For instance, an electronic device may includenon-volatile memory (with slower read/write times) and volatile memory(e.g., dynamic random-access memory (DRAM), static random-access memory(SRAM)). Non-volatile memory persists code/data even when the electronicdevice is turned off or when power is otherwise removed, and theelectronic device copies that part of the code that is to be executed bythe set of processors of that electronic device from the non-volatilememory into the volatile memory of that electronic device duringoperation because volatile memory typically has faster read/write times.As another example, an electronic device may include a non-volatilememory (e.g., phase change memory) that persists code/data when theelectronic device has power removed, and that has sufficiently fastread/write times such that, rather than copying the part of the code tobe executed into volatile memory, the code/data may be provided directlyto the set of processors (e.g., loaded into a cache of the set ofprocessors). In other words, this non-volatile memory operates as bothlong term storage and main memory, and thus the electronic device mayhave no or only a small amount of volatile memory for main memory.

In addition to storing code and/or data on machine-readable storagemedia, typical electronic devices can transmit and/or receive codeand/or data over one or more machine-readable transmission media (alsocalled a carrier) (e.g., electrical, optical, radio, acoustical or otherforms of propagated signals—such as carrier waves, and/or infraredsignals). For instance, typical electronic devices also include a set ofone or more physical network interface(s) to establish networkconnections (to transmit and/or receive code and/or data usingpropagated signals) with other electronic devices. Thus, an electronicdevice may store and transmit (internally and/or with other electronicdevices over a network) code and/or data with one or moremachine-readable media (also referred to as computer-readable media).

Software instructions (also referred to as instructions) are capable ofcausing (also referred to as operable to cause and configurable tocause) a set of processors to perform operations when the instructionsare executed by the set of processors. The phrase “capable of causing”(and synonyms mentioned above) includes various scenarios (orcombinations thereof), such as instructions that are always executedversus instructions that may be executed. For example, instructions maybe executed: 1) only in certain situations when the larger program isexecuted (e.g., a condition is fulfilled in the larger program; an eventoccurs such as a software or hardware interrupt, user input (e.g., akeystroke, a mouse-click, a voice command); a message is published,etc.); or 2) when the instructions are called by another program or partthereof (whether or not executed in the same or a different process,thread, lightweight thread, etc.). These scenarios may or may notrequire that a larger program, of which the instructions are a part, becurrently configured to use those instructions (e.g., may or may notrequire that a user enables a feature, the feature or instructions beunlocked or enabled, the larger program is configured using data and theprogram's inherent functionality, etc.). As shown by these exemplaryscenarios, “capable of causing” (and synonyms mentioned above) does notrequire “causing” but the mere capability to cause. While the term“instructions” may be used to refer to the instructions that whenexecuted cause the performance of the operations described herein, theterm may or may not also refer to other instructions that a program mayinclude. Thus, instructions, code, program, and software are capable ofcausing operations when executed, whether the operations are alwaysperformed or sometimes performed (e.g., in the scenarios describedpreviously). The phrase “the instructions when executed” refers to atleast the instructions that when executed cause the performance of theoperations described herein but may or may not refer to the execution ofthe other instructions.

Electronic devices are designed for and/or used for a variety ofpurposes, and different terms may reflect those purposes (e.g., userdevices, network devices). Some user devices are designed to mainly beoperated as servers (sometimes referred to as server devices), whileothers are designed to mainly be operated as clients (sometimes referredto as client devices, client computing devices, client computers, or enduser devices; examples of which include desktops, workstations, laptops,personal digital assistants, smartphones, wearables, augmented reality(AR) devices, virtual reality (VR) devices, mixed reality (MR) devices,etc.). The software executed to operate a user device (typically aserver device) as a server may be referred to as server software orserver code), while the software executed to operate a user device(typically a client device) as a client may be referred to as clientsoftware or client code. A server provides one or more services (alsoreferred to as serves) to one or more clients.

The term “user” refers to an entity (e.g., an individual person) thatuses an electronic device. Software and/or services may use credentialsto distinguish different accounts associated with the same and/ordifferent users. Users can have one or more roles, such asadministrator, programmer/developer, and end user roles. As anadministrator, a user typically uses electronic devices to administerthem for other users, and thus an administrator often works directlyand/or indirectly with server devices and client devices.

FIG. 4A is a block diagram illustrating an electronic device 400according to some example implementations. FIG. 4A includes hardware 420comprising a set of one or more processor(s) 422, a set of one or morenetwork interfaces 424 (wireless and/or wired), and machine-readablemedia 426 having stored therein software 428 (which includesinstructions executable by the set of one or more processor(s) 422). Themachine-readable media 426 may include non-transitory and/or transitorymachine-readable media. Each of the previously described clients andconsolidated order manager may be implemented in one or more electronicdevices 400.

During operation, an instance of the software 428 (illustrated asinstance 406 and referred to as a software instance; and in the morespecific case of an application, as an application instance) isexecuted. In electronic devices that use compute virtualization, the setof one or more processor(s) 422 typically execute software toinstantiate a virtualization layer 408 and one or more softwarecontainer(s) 404A-404R (e.g., with operating system-levelvirtualization, the virtualization layer 408 may represent a containerengine running on top of (or integrated into) an operating system, andit allows for the creation of multiple software containers 404A-404R(representing separate user space instances and also calledvirtualization engines, virtual private servers, or jails) that may eachbe used to execute a set of one or more applications; with fullvirtualization, the virtualization layer 408 represents a hypervisor(sometimes referred to as a virtual machine monitor (VMM)) or ahypervisor executing on top of a host operating system, and the softwarecontainers 404A-404R each represent a tightly isolated form of asoftware container called a virtual machine that is run by thehypervisor and may include a guest operating system; withpara-virtualization, an operating system and/or application running witha virtual machine may be aware of the presence of virtualization foroptimization purposes). Again, in electronic devices where computevirtualization is used, during operation, an instance of the software428 is executed within the software container 404A on the virtualizationlayer 408. In electronic devices where compute virtualization is notused, the instance 406 on top of a host operating system is executed onthe “bare metal” electronic device 400. The instantiation of theinstance 406, as well as the virtualization layer 408 and softwarecontainers 404A-404R if implemented, are collectively referred to assoftware instance(s) 402.

Alternative implementations of an electronic device may have numerousvariations from that described above. For example, customized hardwareand/or accelerators might also be used in an electronic device.

FIG. 4B is a block diagram of a deployment environment according to someexample implementations. A system 440 includes hardware (e.g., a set ofone or more server devices) and software to provide service(s) 442,including a consolidated order manager. In some implementations thesystem 440 is in one or more datacenter(s). These datacenter(s) maybe: 1) first party datacenter(s), which are datacenter(s) owned and/oroperated by the same entity that provides and/or operates some or all ofthe software that provides the service(s) 442; and/or 2) third-partydatacenter(s), which are datacenter(s) owned and/or operated by one ormore different entities than the entity that provides the service(s) 442(e.g., the different entities may host some or all of the softwareprovided and/or operated by the entity that provides the service(s)442). For example, third-party datacenters may be owned and/or operatedby entities providing public cloud services.

The system 440 is coupled to user devices 480A-480S over a network 482.The service(s) 442 may be on-demand services that are made available toone or more of the users 484A-484S working for one or more entitiesother than the entity which owns and/or operates the on-demand services(those users sometimes referred to as outside users) so that thoseentities need not be concerned with building and/or maintaining asystem, but instead may make use of the service(s) 442 when needed(e.g., when needed by the users 484A-484S). The service(s) 442 maycommunicate with each other and/or with one or more of the user devices480A-480S via one or more APIs (e.g., a REST API). In someimplementations, the user devices 480A-480S are operated by users484A-484S, and each may be operated as a client device and/or a serverdevice. In some implementations, one or more of the user devices480A-480S are separate ones of the electronic device 400 or include oneor more features of the electronic device 400.

In some implementations, the system 440 is a multi-tenant system (alsoknown as a multi-tenant architecture). The term multi-tenant systemrefers to a system in which various elements of hardware and/or softwareof the system may be shared by one or more tenants. A multi-tenantsystem may be operated by a first entity (sometimes referred to amulti-tenant system provider, operator, or vendor; or simply a provider,operator, or vendor) that provides one or more services to the tenants(in which case the tenants are customers of the operator and sometimesreferred to as operator customers). A tenant includes a group of userswho share a common access with specific privileges. The tenants may bedifferent entities (e.g., different companies, differentdepartmnents/divisions of a company, and/or other types of entities),and some or all of these entities may be vendors that sell or otherwiseprovide products and/or services to their customers (sometimes referredto as tenant customers). A multi-tenant system may allow each tenant toinput tenant specific data for user management, tenant-specificfunctionality, configuration, customizations, non-functional properties,associated applications, etc. A tenant may have one or more rolesrelative to a system and/or service. For example, in the context of acustomer relationship management (CRM) system or service, a tenant maybe a vendor using the CRM system or service to manage information thetenant has regarding one or more customers of the vendor. As anotherexample, in the context of Data as a Service (DAAS), one set of tenantsmay be vendors providing data and another set of tenants may becustomers of different ones or all of the vendors' data. As anotherexample, in the context of Platform as a Service (PAAS), one set oftenants may be third-party application developers providingapplications/services and another set of tenants may be customers ofdifferent ones or all of the third-party application developers.

Multi-tenancy can be implemented in different ways. In someimplementations, a multi-tenant architecture may include a singlesoftware instance (e.g., a single database instance) which is shared bymultiple tenants; other implementations may include a single softwareinstance (e.g., database instance) per tenant; yet other implementationsmay include a mixed model; e.g., a single software instance (e.g., anapplication instance) per tenant and another software instance (e.g.,database instance) shared by multiple tenants.

In one implementation, the system 440 is a multi-tenant cloud computingarchitecture supporting multiple services, such as one or more of thefollowing types of services: Customer relationship management (CRM);Configure, price, quote (CPQ); Business process modeling (BPM); Customersupport; Marketing; Productivity; Database-as-a-Service;Data-as-a-Service (DAAS or DaaS); Platform-as-a-service (PAAS or PaaS);Infrastructure-as-a-Service (IAAS or IaaS) (e.g., virtual machines,servers, and/or storage); Analytics; Community; Internet-of-Things(IoT); Industry-specific; Artificial intelligence (AI); Applicationmarketplace (“app store”); Data modeling; Security; and Identity andaccess management (IAM). For example, system 440 may include anapplication platform 444 that enables PAAS for creating, managing, andexecuting one or more applications developed by the provider of theapplication platform 444, users accessing the system 440 via one or moreof user devices 480A-480S, or third-party application developersaccessing the system 440 via one or more of user devices 480A-480S.

In some implementations, one or more of the service(s) 442 may use oneor more multi-tenant databases 446, as well as system data storage 450for system data 452 accessible to system 440. In certainimplementations, the system 440 includes a set of one or more serversthat are running on server electronic devices and that are configured tohandle requests for any authorized user associated with any tenant(there is no server affinity for a user and/or tenant to a specificserver). The user devices 480A-480S communicate with the server(s) ofsystem 440 to request and update tenant-level data and system-level datahosted by system 440, and in response the system 440 (e.g., one or moreservers in system 440) automatically may generate one or more StructuredQuery Language (SQL) statements (e.g., one or more SQL queries) that aredesigned to access the desired information from the multi-tenantdatabase(s) 446 and/or system data storage 450.

In some implementations, the service(s) 442 are implemented usingvirtual applications dynamically created at run time responsive toqueries from the user devices 480A-480S and in accordance with metadata,including: 1) metadata that describes constructs (e.g., forms, reports,workflows, user access privileges, business logic) that are common tomultiple tenants; and/or 2) metadata that is tenant specific anddescribes tenant specific constructs (e.g., tables, reports, dashboards,interfaces, etc.) and is stored in a multi-tenant database. To that end,the program code 460 may be a runtime engine that materializesapplication data from the metadata; that is, there is a clear separationof the compiled runtime engine (also known as the system kernel), tenantdata, and the metadata, which makes it possible to independently updatethe system kernel and tenant-specific applications and schemas, withvirtually no risk of one affecting the others. Further, in oneimplementation, the application platform 444 includes an applicationsetup mechanism that supports application developers' creation andmanagement of applications, which may be saved as metadata by saveroutines. Invocations to such applications, including the framework formodeling heterogeneous feature sets, may be coded using ProceduralLanguage/Structured Object Query Language (PL/SOQL) that provides aprogramming language style interface. Invocations to applications may bedetected by one or more system processes, which manages retrievingapplication metadata for the tenant making the invocation and executingthe metadata as an application in a software container (e.g., a virtualmachine).

Network 482 may be any one or any combination of a LAN (local areanetwork), WAN (wide area network), telephone network, wireless network,point-to-point network, star network, token ring network, hub network,or other appropriate configuration. The network may comply with one ormore network protocols, including an Institute of Electrical andElectronics Engineers (IEEE) protocol, a 3rd Generation PartnershipProject (3GPP) protocol, a 4^(th) generation wireless protocol (4G)(e.g., the Long Term Evolution (LTE) standard, LTE Advanced, LTEAdvanced Pro), a fifth generation wireless protocol (5G), and/or similarwired and/or wireless protocols, and may include one or moreintermediary devices for routing data between the system 440 and theuser devices 480A-480S.

Each user device 480A-480S (such as a desktop personal computer,workstation, laptop, Personal Digital Assistant (PDA), smartphone,smartwatch, wearable device, augmented reality (AR) device, virtualreality (VR) device, etc.) typically includes one or more user interfacedevices, such as a keyboard, a mouse, a trackball, a touch pad, a touchscreen, a pen or the like, video or touch free user interfaces, forinteracting with a graphical user interface (GUI) provided on a display(e.g., a monitor screen, a liquid crystal display (LCD), a head-updisplay, a head-mounted display, etc.) in conjunction with pages, forms,applications and other information provided by system 440. For example,the user interface device can be used to access data and applicationshosted by system 440, and to perform searches on stored data, andotherwise allow one or more of users 484A-484S to interact with variousGUI pages that may be presented to the one or more of users 484A-484S.User devices 480A-480S might communicate with system 440 using TCP/IP(Transfer Control Protocol and Internet Protocol) and, at a highernetwork level, use other networking protocols to communicate, such asHypertext Transfer Protocol (HTTP), File Transfer Protocol (FTP), AndrewFile System (AFS), Wireless Application Protocol (WAP), Network FileSystem (NFS), an application program interface (API) based uponprotocols such as Simple Object Access Protocol (SOAP), RepresentationalState Transfer (REST), etc. In an example where HTTP is used, one ormore user devices 480A-480S might include an HTTP client, commonlyreferred to as a “browser,” for sending and receiving HTTP messages toand from server(s) of system 440, thus allowing users 484A-484S of theuser devices 480A-480S to access, process and view information, pagesand applications available to it from system 440 over network 482.

In the above description, numerous specific details such as resourcepartitioning/sharing/duplication implementations, types andinterrelationships of system components, and logicpartitioning/integration choices are set forth in order to provide amore thorough understanding. The invention may be practiced without suchspecific details, however. In other instances, control structures, logicimplementations, opcodes, means to specify operands, and full softwareinstruction sequences have not been shown in detail since those ofordinary skill in the art, with the included descriptions, will be ableto implement what is described without undue experimentation.

References in the specification to “one implementation,” “animplementation,” “an example implementation,” etc., indicate that theimplementation described may include a particular feature, structure, orcharacteristic, but every implementation may not necessarily include theparticular feature, structure, or characteristic. Moreover, such phrasesare not necessarily referring to the same implementation. Further, whena particular feature, structure, and/or characteristic is described inconnection with an implementation, one skilled in the art would know toaffect such feature, structure, and/or characteristic in connection withother implementations whether or not explicitly described.

For example, the figure(s) illustrating flow diagrams sometimes refer tothe figure(s) illustrating block diagrams, and vice versa. Whether ornot explicitly described, the alternative implementations discussed withreference to the figure(s) illustrating block diagrams also apply to theimplementations discussed with reference to the figure(s) illustratingflow diagrams, and vice versa. At the same time, the scope of thisdescription includes implementations, other than those discussed withreference to the block diagrams, for performing the flow diagrams, andvice versa.

Bracketed text and blocks with dashed borders (e.g., large dashes, smalldashes, dot-dash, and dots) may be used herein to illustrate optionaloperations and/or structures that add additional features to someimplementations. However, such notation should not be taken to mean thatthese are the only options or optional operations, and/or that blockswith solid borders are not optional in certain implementations.

The detailed description and claims may use the term “coupled,” alongwith its derivatives. “Coupled” is used to indicate that two or moreelements, which may or may not be in direct physical or electricalcontact with each other, co-operate or interact with each other.

While the flow diagrams in the figures show a particular order ofoperations performed by certain implementations, such order is exemplaryand not limiting (e.g., alternative implementations may perform theoperations in a different order, combine certain operations, performcertain operations in parallel, overlap performance of certainoperations such that they are partially in parallel, etc.).

While the above description includes several example implementations,the invention is not limited to the implementations described and can bepracticed with modification and alteration within the spirit and scopeof the appended claims. The description is thus illustrative instead oflimiting.

What is claimed is:
 1. A computer-implemented method for efficientrouting based on content metadata, the method comprising: receiving, bya content distribution network (CDN), a user request for content from aclient, the user request comprising metadata; parsing the user requestfor content, by the CDN, to generate an evaluation of the metadata;determining, by the CDN, a routing decision for the user request forcontent, wherein: the routing decision represents a selection of one ofa plurality of origin services; and the routing decision is based on theevaluation of the metadata; transmitting, by the CDN, the user requestfor content to the selected one of the plurality of origin servicesbased on the routing decision; receiving, by the CDN, a response to theuser request for content from the selected one of the plurality oforigin services; and sending, by the CDN, the response to the client. 2.The computer-implemented method of claim 1, wherein the user request forcontent is an application programming interface (API) call.
 3. Thecomputer-implemented method of claim 1, wherein the metadata comprisesone or more elements selected from the group consisting of: a uniformresource identifier (URI) path; a header; a configuration; anidentification; a latency; and information associated with a source ofthe user request for content.
 4. The computer-implemented method ofclaim 1, further comprising caching, by the CDN, the response prior tosending the response to the client.
 5. The computer-implemented methodof claim 1, further comprising: receiving, by the CDN, a second userrequest for content from the client, the second user request comprisingsecond metadata; parsing the second user request for content, by theCDN, to generate a second evaluation of the second metadata;determining, by the CDN, a second routing decision for the second userrequest for content representing a selection of a different one of theplurality of origin services based on the second evaluation of thesecond metadata; transmitting, by the CDN, the second user request forcontent to the selected different one of the plurality of originservices based on the second routing decision; receiving, by the CDN, asecond response to the second user request for content from the selecteddifferent one of the plurality of origin services; and sending, by theCDN, the second response to the client.
 6. The computer-implementedmethod of claim 1, further comprising: receiving, by the CDN, a seconduser request for content from a second client, the second user requestcomprising second metadata; parsing the second user request for content,by the CDN, to generate a second evaluation of the second metadata;determining, by the CDN, a second routing decision for the second userrequest for content representing a selection of a different one of theplurality of origin services based on the second evaluation of thesecond metadata; transmitting, by the CDN, the second user request forcontent to the selected different one of the plurality of originservices based on the second routing decision; receiving, by the CDN, asecond response to the second user request for content from the selecteddifferent one of the plurality of origin services; and sending, by theCDN, the second response to the client.
 7. A non-transitorymachine-readable storage medium that provides instructions that, ifexecuted by a processor, are configurable to cause the processor toperform operations comprising: receiving, by a content distributionnetwork (CDN), a user request for content from a client, the userrequest comprising metadata; parsing the user request for content, bythe CDN, to generate an evaluation of the metadata; determining, by theCDN, a routing decision for the user request for content, wherein: therouting decision represents a selection of one of a plurality of originservices; and the routing decision is based on the evaluation of themetadata; transmitting, by the CDN, the user request for content to theselected one of the plurality of origin services based on the routingdecision; receiving, by the CDN, a response to the user request forcontent from the selected one of the plurality of origin services; andsending, by the CDN, the response to the client.
 8. The non-transitorymachine-readable storage medium of claim 7, wherein the user request forcontent is an application programming interface (API) call.
 9. Thenon-transitory machine-readable storage medium of claim 7, wherein themetadata comprises one or more elements selected from the groupconsisting of: a uniform resource identifier (URI) path; a header; aconfiguration; an identification; a latency; and information associatedwith a source of the user request for content.
 10. The non-transitorymachine-readable storage medium of claim 7, wherein the operationsfurther comprise caching, by the CDN, the response prior to sending theresponse to the client.
 11. The non-transitory machine-readable storagemedium of claim 7, wherein the operations further comprise: receiving,by the CDN, a second user request for content from the client, thesecond user request comprising second metadata; parsing the second userrequest for content, by the CDN, to generate a second evaluation of thesecond metadata; determining, by the CDN, a second routing decision forthe second user request for content representing a selection of adifferent one of the plurality of origin services based on the secondevaluation of the second metadata; transmitting, by the CDN, the seconduser request for content to the selected different one of the pluralityof origin services based on the second routing decision; receiving, bythe CDN, a second response to the second user request for content fromthe selected different one of the plurality of origin services; andsending, by the CDN, the second response to the client.
 12. Thenon-transitory machine-readable storage medium of claim 7, wherein theoperations further comprise: receiving, by the CDN, a second userrequest for content from a second client, the second user requestcomprising second metadata; parsing the second user request for content,by the CDN, to generate a second evaluation of the second metadata;determining, by the CDN, a second routing decision for the second userrequest for content representing a selection of a different one of theplurality of origin services based on the second evaluation of thesecond metadata; transmitting, by the CDN, the second user request forcontent to the selected different one of the plurality of originservices based on the second routing decision; receiving, by the CDN, asecond response to the second user request for content from the selecteddifferent one of the plurality of origin services; and sending, by theCDN, the second response to the client.
 13. An apparatus comprising: aprocessor; and a non-transitory machine-readable storage medium thatprovides instructions that, if executed by a processor, are configurableto cause the processor to perform operations comprising: receiving, by acontent distribution network (CDN), a user request for content from aclient, the user request comprising metadata; parsing the user requestfor content, by the CDN, to generate an evaluation of the metadata;determining, by the CDN, a routing decision for the user request forcontent, wherein: the routing decision represents a selection of one ofa plurality of origin services; and the routing decision is based on theevaluation of the metadata; transmitting, by the CDN, the user requestfor content to the selected one of the plurality of origin servicesbased on the routing decision; receiving, by the CDN, a response to theuser request for content from the selected one of the plurality oforigin services; and sending, by the CDN, the response to the client.14. The apparatus of claim 13, wherein the user request for content isan application programming interface (API) call.
 15. The apparatus ofclaim 13, wherein the metadata comprises one or more elements selectedfrom the group consisting of: a uniform resource identifier (URI) path;a header; a configuration; an identification; a latency; and informationassociated with a source of the user request for content.
 16. Theapparatus of claim 13, wherein the operations further comprise caching,by the CDN, the response prior to sending the response to the client.17. The apparatus of claim 13, wherein the operations further comprise:receiving, by the CDN, a second user request for content from theclient, the second user request comprising second metadata; parsing thesecond user request for content, by the CDN, to generate a secondevaluation of the second metadata; determining, by the CDN, a secondrouting decision for the second user request for content representing aselection of a different one of the plurality of origin services basedon the second evaluation of the second metadata; transmitting, by theCDN, the second user request for content to the selected different oneof the plurality of origin services based on the second routingdecision; receiving, by the CDN, a second response to the second userrequest for content from the selected different one of the plurality oforigin services; and sending, by the CDN, the second response to theclient.
 18. The apparatus of claim 13, wherein the operations furthercomprise: receiving, by the CDN, a second user request for content froma second client, the second user request comprising second metadata;parsing the second user request for content, by the CDN, to generate asecond evaluation of the second metadata; determining, by the CDN, asecond routing decision for the second user request for contentrepresenting a selection of a different one of the plurality of originservices based on the second evaluation of the second metadata;transmitting, by the CDN, the second user request for content to theselected different one of the plurality of origin services based on thesecond routing decision; receiving, by the CDN, a second response to thesecond user request for content from the selected different one of theplurality of origin services; and sending, by the CDN, the secondresponse to the client.